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[57] ABSTRACT 

A medical records system that creates and maintains all 
patient data electronically. The system captures patient data7 
su ch as patient complaints, lab orders, medicatio ns, 
dia jgnoses.^nd procedu res, at its source at the time of entry 
using a graphical user interface having touch scre ens. Using 
pen-based portable computers with wireless conne ctions lo 
a com puter network, authorized healthcare proviHers can 
accessj_analyze, .u pdate and electronically annotate pat ient 
data even while other providers are using the same patie nt 
recofcTlTie system likewise permits instant, sophisticated 
analysis of patient data to identify relationships among the 
data considered. Moreover, the system includes the capabil- 
ity to access reference databases for consultation regarding 
allergies, medication interactions and practice guidelines. 
The system also includes the capability to incorporate legacy 
data, such as paper files and mainframe data, for a patient. 

46 Claims, 26 Drawing Sheets 
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ELECTRONIC MEDICAL RECORDS abnormal laboratory test results, prescribed medications to 

SYSTEM address the abnormality, and specific treatments adminis- 
tered by the physician, may not be apparent within a patient 

FIELD OF THE INVENTION file. 

The present invention relates to electronic healthcare 5 In the current environment, specific patient data is difficult 

systems, and more particularly, to a system for storage and t0 access when needed for analysis. The creation of patient 

retrieval of electronic medical records in a computer data in remote locations exacerbates this problem. In 

environment, such as a local or wide area network including addition, the wide variety of data formats for patient data 

portable computers. hinders electronic processing and maintenance of patient 

10 files. Moreover, the use of a patient's file by one healthcare 

DESCRIPTION OF RELATED TECHNOLOGY provider can preclude its simultaneous use by another 

Healthcare providers, such as physicians, create large healtl \ care F r ° V f n ™™^ation of healthcare 

, r *■ * • r j ■ *i_ rtL ■ providers into large health maintenance organizations 

volumes of patient information during the course of their , ¥T w^ \ ^ r j j \ 

, . * U ia. r » i . t , ,. . (HMOs) and preferred provider organizations (PPOs) create 

business at healthcare facilities, such as hospitals, clinics, 1<; > . ' , r r » , & c A . \ , , < t 

i . . • j j- 1 a- r i u 15 issues in the transfer and maintenance of patient data in large 

laboratones and medical offices. For example, when a 4 • L • i • »i j i 

t . 4 . . t . • * r iL a A *l l • * enterprises having numerous remote locations. Under these 

patient visits a physician for the first time, the physician r . . , l4 . , 

r „ . *• * ci ■ i j- iL j- circumstances, healthcare providers have difficulty provid- 

generally creates a patient file including the patient s medi- . . r t_ • • 

i , • 4 4 4 . j- T* ■ j ing effective treatment for their patients, 

cal history, current treatments, medications, insurance and ° r 

other pertinent information. This file generally includes the 20 SUMMARY OF THE INVENTION 
results of patient visits, including laboratory test results, the 

physician's diagnosis, medications prescribed and treat- The electronic medical record (EMR) system of the 

ments administered. During the course of the patient present invention automates and simplifies existing methods 

relationship, the physician supplements the file to update the of patient chart creation, maintenance and retrieval. In 

patient's medical history. When the physician refers a 25 contrast to other systems, the present invention creates and 

patient for treatment, tests or consultation, the referred maintains all patient data electronically and thus can elimi- 

physician, hospital, clinic or laboratory typically creates and nate or supplement creating and maintaining of physical data 

updates similar files for the patient. These files may also records. The EMR system finishes healthcare providers with 

include the patient's billing, payment and scheduling an intuitive, easy-to-use, icon-based interface that enables 

records. 30 them to capture and analyze patient data quickly and effi- 

Healthcare providers can use electronic data processing to ciently. Using the present invention, healthcare providers 

automate the creation, use and maintenance of their patient enter patient data immediately at the point of care. Thus, the 

records. For example, in U.S. Pat. No. 5,277,188, assigned EMR system captures each piece of data at its source at the 

to New England Medical Center Hospitals, Inc., Selker time of entry to provide a complete audit trail for all patient 

discloses a clinical information reporting system having an 35 data - In tnis manner, the EMR system transforms a patient 

electronic database including electrocardiograph related cnart from a static record of a few clinical interactions into 

patient data. Similarly, Schneiderman discloses a computer a dynamic, real-time comprehensive record linked to an 

system for recording electrocardiograph and/or chest x-ray enterprise- wide clinical database. In addition, the EMR 

test results for a database of patients in U.S. Pat. No. system of the present invention includes the capability to 

5,099,424. In U.S. Pat. No. 4,315,309, Coli discloses a 40 manage a wide variety of patient data formats, including 

patient report generating system for receiving, storing and patient data from external sources, such as laboratories and 

reporting medical test data for a patient population. Mitchell, pharmacies. The EMR system can also incorporate a 

in U.S. Pat. No. 3,872,448, likewise discloses a system for patient's legacy data, such as a paper chart, into the patient 

automatically handling and processing hospital data, such as record as well as legacy data from mainframe computers, 

patient information and pathological test information using 45 The present invention likewise provides instant access to 

a central processing apparatus. In U.S. Pat. No. 5,065,315, a patient's electronic medical record by authorized health- 

Garcia discloses a computerized scheduling and reporting care providers from any geographical location. Thus, the 

system for managing information pertinent to a patient's EMR system enables authorized healthcare providers to 

stay in the hospital. However, these electronic data process- access and update patient files using wireless pen-based 

ing systems can not handle patient data in the wide variety 50 personal computers. To enable complete replacement of 

of data formats typically produced by healthcare providers, physical records, the present invention permits healthcare 

such as physicians, laboratories, clinics and hospitals. providers, such as physicians or nurse practitioners, to 

Physicians often use paper based forms and charts to electronically annotate patient data. Thus, a healthcare pro- 
document their observations and diagnosis. Laboratories vider can acknowledge reviewing patient data, provide 
also produce patient data in numerous forms, from x-ray and 55 instructions, such as prescriptions for medication to admin- 
magnetic resonance images to blood test concentrations and ister to a patient, and approve recommendations for treat- 
electrocardiograph data. Clinics and hospitals may use a ment by other providers, all by electronically annotating a 
combination of paper based charts and electronic data for patient's record. In addition, authorized healthcare providers 
patient records. The same patient data may exist in remote can access a record while other providers use the same 
patient files located at clinics, hospitals, laboratories and 60 record allowing for real-time collaboration. The availability 
physicians' offices. Similarly, patient files at one healthcare of electronic data permits instant, sophisticated analysis of 
provider typically have different information than patient patient data. Moreover, the EMR system enables enhanced 
files at another healthcare provider. When in use, patient files analysis of patient data by providing access to reference 
are generally not available to other healthcare providers. In databases for diagnosis, procedures and medication, 
addition, at the time of creation, patient data is generally not 65 One aspect of the present invention includes a medical 
available for use by remotely located healthcare providers. records system, comprising a point of care system to capture 
Moreover, relationships among specific patient data, such as patient data at a point of care and a patient data repository, 
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in communication with the point of care system and with 
external systems, to store and organize the patient data for 
access by the point of care system. 

Another aspect of the present invention includes a medi- 
cal records system comprising a point of care system to 5 
capture data in a patient record at a point of care, wherein the 
patient record includes a patient identifier and at least one 
data structure including the patient identifier and the data. 

Yet another aspect of the present invention includes a 
medical records system comprising a point of care system to 30 
capture data at a point of care and a patient data repository, 
in communication with the point of care system and with 
external systems to store and organize the data in a patient 
record for access by the point of care system, wherein the 
patient record includes a patient identifier and at least one 15 
data structure including the patient identifier and the data. 

In addition, another aspect of the present invention 
includes a method of using an electronic medical records 
system, comprising the steps of capturing patient data elec- 
tronically at the point of care, organizing the patient data so 20 
as to form a patient record, filing the patient record, and 
retrieving the patient record to access the patient data for use 
in the care of a patient. 

Yet another aspect of the present invention includes a 
method of retrieving patient data in an electronic medical 25 
records system having a patient data repository, comprising 
the steps of obtaining a patient identifier, locating a patient 
record corresponding to the patient identifier in the patient 
data repository, and determining the location of the patient 
data within the patient record. 30 

Another aspect of the present invention includes a method 
of managing a patient data repository having a cache and a 
data archive, comprising the steps of monitoring a status of 
data within the cache, and moving the data to the data 
archive when the status exceeds a threshold. 35 

Still another aspect of the present invention includes a 
method of communicating with an external source having an 
interface to an electronic medical records system, compris- 
ing the steps of finding an interface for the external source, 
connecting to the external source using the interface, and 40 
converting patient data for transfer between the external 
source and the electronic medical records system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram illustrating the electronic 45 
medical record (EMR) system architecture of the present 
invention. 

FIG. 2 is a flowchart illustrating the process flow of the 
EMR system of the present invention. 

FIG. 3 shows an example of a graphical user interface of 50 
the EMR system useful for the scheduling of a patient 
appointment as shown in FIG. 2. 

FIG. 4 is a block diagram illustrating the structure of the 
point of care system of FIG. 1. 55 

FIG. 5 shows an example of a graphical user interface of 
the point of care system of FIG. 4. 

FIG. 6 shows an example of a new form window of the 
point of care system of FIG. 4. 

FIG. 7 shows an example of an annotate window of the 60 
point of care system of FIG. 4. 

FIG. 8 shows an example of a viewer window displaying 
an image of patient data of the point of care system of FIG. 
4. 

FIG. 9 is a block diagram illustrating the structure of a 65 
medication data capture in the point of care system of FIG. 
4. 



,074 

4 

FIG. 10 is a block diagram illustrating the structure of a 
practice guideline in the point of care system of FIG. 4. 

FIG. 11 is a block diagram illustrating the structure of the 
medication data capture and the practice guideline in the 
point of care system of FIG. 4. 

FIG. 12 is a block diagram illustrating the structure of the 
patient data repository of FIG. 1. 

FIG. 13 is a block diagram illustrating the structure of a 
patient record within the patient data repository of FIG; 12. 

FIG. 14 is an example of the patient record of FIG. 13. 

FIG. 15a is a flowchart illustrating the process flow of the 
patient data repository of FIG. 12. 

FIG. 15b is a flowchart illustrating the process for a 
transfer of data from a cache to a data archive in the patient 
data repository of FIG. 12. 

FIG. 16 is a block diagram illustrating the structure of the 
data interface of FIG. 12. 

FIG. 17a is a flowchart illustrating the process flow of the 
data interface of FIG. 16 when receiving patient data from 
an external source. 

FIG. 176 is a flowchart illustrating the process flow of the 
data interface of FIG. 16 when transmitting patient data to 
an external source. 

FIG. 18 is a block diagram illustrating the structure of the 
reference database of FIG. 1, 

FIG. 19 shows an example of a graphical user interface of 
the point of care system of FIG. 4 having a reference access 
button and a medication manager button. 

FIG. 20 shows an example of a graphical user interface 
for the diagnosis module and the procedure module of the 
reference database of FIG. 18. 

FIG. 21 shows an example of a graphical user interface 
for the medication manager of the reference database of FIG. 
18. 

FIG. 22 shows an example of a medication interaction 
window of the medication manager of FIG. 21. 

FIG. 23 is a block diagram illustrating the structure of the 
legacy data system of FIG. 1. 

FIG. 24 is an example of a typical configuration for the 
electronic medical records system of the present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

The following detailed description of the preferred 
embodiments presents a description of certain specific 
embodiments to assist in understanding the claims. 
However, one may practice the present invention in a 
multitude of different embodiments as defined and covered 
by the claims. 

For convenience, the description comprises three sec- 
tions: EMR System Architecture and Overview, EMR Sys- 
tem Configurations and Summary. The first section provides 
an overview of the EMR system architecture, the following 
section describes EMR system applications and preferred 
embodiments for practicing the EMR system of the present 
invention, and the remaining section summarizes advanta- 
geous features of the present invention. 

I. EMR System Architecture and Overview 

FIG. 1 illustrates the architecture of the EMR system. 
Healthcare providers, such as physicians, at hospitals, labo- 
ratories and clinics, generally capture and access patient data 
using a point of care system 100 that communicates with a 
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patient data repository 102. Patient data, such as vital signs, a reappointment date and an appointment time. An adjac ent 

x-ray images and laboratory results, resides in the patient box, su chas the "dale box 126, dis plays the selected da te and 

data repository 102. The patient data repository 102 also time. Lastly, t he neaimcare provider enters a textual des crip- 

communicates with external sources to obtain patient data, tion of the patient's complaint in a reason box 127. Note that 

such as laboratory test results and x-ray images, and to 5 the healthcare pivwldtti i:sm-g£ v:iew prjorgp^Bt irTr^hediiled 

transfer patient information, such as prescriptions for appomtmetrts-iy^ickmg^n^u^appoinTments button 128. 

medication, from the EMR system to other healthcare pro- Similarly, the ne^theare-^provider can track referrals by 

viders. The point of care system 100 captures patient data in entering the identity of persons who referred this patient to 

real-time at the point of care, that is, where healthcare their care in the referral box. 129. 

providers interact with their patients. For example, physi- 3 q Referring now to FIG. 4, a block diagram illustrates the 
cians can use a point of care system 100 to enter, access, structure of the point of care system 100. The point of care 
process, analyze and annotate data from patient records in system 100 includes the following modules: a patient data 
real-time at the point of care. Thus, using the point of care capture 140, a clinical data capture 142, progress notes 144 
system 100, a physician, who has many patients in a and an encounter data capture 146. During a patient visit, the 
hospital, can visit each patient in their room, access their ^ healthcare provider (not shown) can enter, review and anno- 
electronic patient record there, enter results of the current tate patient information, such as family history, 
examination, evaluate their medical history, electronically appointments, current medications and complaints, using the 
annotate their x-rays images and prescribe medications and patient data capture 140. The healthcare provider can like- 
treatments instantaneously as the point of care system 100 wise enter, review and annotate clinical data obtained during 
captures and organizes patient data into the patient record 2 o the visit, such as body temperature and blood pressure, using 
stored in the patient data repository 102. The point of care the clinical data capture 142. Similarly, the healthcare pro- 
system 100 may likewise communicate with a reference vider can enter laboratory data for patients with the clinical 
database 104 to assist a healthcare provider in making data capture 142. The clinical data capture 142 communi- 
diagnoses, prescribing medications and administering treat- cates with the patient data capture 140 to assist in identifying 
ments. Moreover, the patient data repository 102 may also 2 s needs for further clinical data. For example, a family history 
communicate with a legacy data system 106 to access of high blood pressure may indicate a need to obtain the 
pertinent patient data in paper files and mainframe electronic patient's blood pressure during the visit. The patient data 
databases. capture 140 also communicates with the encounter data 
Referring now to FIG. 2, a flowchart illustrates the capture 146, where a healthcare provider can enter, review 
operation of the EMR system. For example, a patient having 30 and annotate data regarding diagnoses and procedures 
a complaint contacts a healthcare provider 110, such as a administered to the patient. Moreover, the healthcare pro- 
physician, to schedule an appointment. The EMR system vider can use the progress notes 144 to summarize details of 
obtains the patient record 111 from the patient data reposi- the patient's condition and to review the patient's progress 
tory 102 (FIG. 1) prior to the scheduled appointment. The over time. Thus, the progress notes 144 communicates with 
EMR system is also capable of handling patients on a 35 the patient data capture 140, the clinical data capture 142 
walk-in basis by scheduling an appointment and requesting and the encounter data capture 146. 
the patient's record immediately thereafter. The EMR sys- Referring now to FIG. 5, in a preferred embodiment, the 
tem updates the patient record 112 to include the complaint point of care system 100 (FIG, 1) includes a graphical user 
and other information pertinent to the appointment, such as interface having a patient chart window 150 to capture 
insurance information. A healthcare provider, such as a 40 patient information. The point of care system 100 presents a 
physician, examines the patient 113 using the point of care patient record graphically using a tabbed layout to organize 
system 100 (FIG. 1) to make a diagnosis and to treat the patient data. The patient chart window 150 includes tabs for 
patient's condition. As determined at 114, if a diagnosis is patient data 151, clinical data 152, encounter data 153 and 
not possible on the basis of this examination, the physician progress notes 154. Pointing and clicking on a tab on the 
may need to obtain additional clinical data 115, such as 45 patient chart window 150 opens a folder window 155 where 
laboratory tests and x-rays. When available, the physician a healthcare provider can enter and review patient data 
uses the point of care system 100 (FIG. 1) to evaluate the within the folder. For example, to activate progress notes 
results 116 and to examine the patient 113 again in light of 144 (FIG. 4), the healthcare provider selects the progress 
the results. Upon making a diagnosis, the physician may notes tab 154 to display a list of progress note data in the 
need to prescribe medications 117 for the patient's condi- 50 folder window 155. In a similar manner, to activate the 
tion. Similarly, the physician may need to administer a patient data capture 140, the clinical data capture 142 or the 
treatment 118 to address the patient's condition. At the encounter data capture 146, one selects the patient data tab 
conclusion of the patient's visit, the EMR system files the 151, the clinical data tab 142, or the encounter data tab 153, 
patient's record 119 in the patient data repository 102 (FIG. respectively. 

1) for future reference. 55 To enter patient data, the healthcare provider clicks on the 

In a pref erred embodiment, the EMR system inc ludes scroll "cloWn button Ibb to select a form" trom a list "of 

g raphicaLuser inte rfaces tojtccess system Jlunctions.~For av ailable forms to enter patient data . 'Ihis activates the new 

cample, as shown in~FlG. 3, a chat Lpuller-.window 120 fo rms box 157. The p rovider then points and clicks on tne 

enables a h ealthcare provider to schedule a patient appoint- new fo rm button 1587"E oi' example, "HO. 6~shgws"a~ne"W r 

mem using its point and^c lick-interface .-To.schedule an 60 fo rm window 161 displayin g the pedia t ri c p r o bl e m fuiWT 62 

appoi ntment, a healthc are provider activates the select but- sel ected by the healthcare p roTrderntsin^'the-scTOlt^own 

t" 6nT2Twith a pointin g deyj,ce,.suc h.as a mo use or electronic buTt on 156 (FIG. S\ The healthc afTTTt ovidert lls outTne 

p en, to obtain a list of patients. The healthcare provider then pe mTtric problem form l 62 using an input device, such as a 

sca ns the list to sele^rth e"name -of-the-a ppropriatC patient key board, a mouse or an electr6riiC^>ei irFDr"example7 the 

using.a^pranling devic^TThTEMR system places t he nam e 65 provi der uses, a kevboard to en ter text Stom ach 

of theLsele^ted-patient in^thg p atient bo x 123^Similarly, tEe* A cfie"~164 and an electronic pen to enter initials 166 for 

healthcare provider uses the up/down buttons 125 to select identification. When done with patient data entry, the pro- 
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vider exits the form using the File Menu 168 and the point the patient data capture 140 and with the progress note 144. 

of care system 100 returns the provider to the patient chart Similarly, the practice guideline 149 communicates with 

window 150 (FIG. 5). Referring back to FIG. 5, the new patient data capture 140, the clinical data capture 142, the 

form appears as the top entry of the list in the folder window encounter data capture 146 and the progress note 144. 

155. 5 However, the practice guideline 149 may now communicate 

Si milarly, to annotate patient data, the healthcare provider with the medication data capture 148 to address situations 

first se lects an item to a nnotate by pointing and clicking on where accepted practice guidelines require a healthcare 

the ife m in a list displayed in the t^cr^i!fdow"155" The provider to prescribe and administer medications. In a 

provi aeTthen clicks on the annotate outtofTlsy to o pen the preferred embodiment, the point of care system 100 includes 

ite m' in an annotate window 170. as sh own in"nGT77"For ]0 m ^ graphical user interface illustrated in FIG. 5. Referring 

example, the annotate window 170 ot FTGrT^isplays a" back to FIG. 5, the patient chart window 150 includes tabs 

b l oad-test result Tf27 As be tore/trl e^eaitfaea re^pisvideY for medication data 191 and practice guidelines 193 that 

annotates the blood test result document \TZ usin g an in put activate the medication data capture 148 and the practice 

dev ice, such as a Keyboard, a mouse or an"electronic pen, for guideline 149, respectively. Similarly, pressing the medica- 

exa mple, the pro vider uses a keyboard to enter text "Out of 35 tion manager button 192 activates the medication data 

R aftge" 174 and an ele75tr^nic^eTrtrr^^ out of capture 148 and the practice guideline 149. A healthcare 

ran ge result. When done with annotations, t he provlBeTex its provider can enter, review and annotate patient medication 

fh %fQ rn " e ^g t he tnle Menu 178 and the point or. care data and practice guideline data as described previously, 

sy stem 100 re turns the provider to tbe patient chart window Referring now to FIG. 12, a block diagram illustrates the 

15 (T(riij. 3>. mrte-that tho-point o f- ca re-systerrTlOO'trgcks 2 o structure of the patient data repository 102. The patient data 

t heTreview or. patient data ancUfleiitin.es rev&wecH iies-wkh repository 102 includes a patient locator 200, a data manager 

a mark 160 in the folder window 155. By annotating patient 202 and a data interface 204. The patient locator 200 

data, a healthcare provider, such as a physician, can generates a unique patient identifier (PID) 221 (FIG. 14) for 

acknowledge reviewing patient data, provide instructions, each patient and creates and maintains a table having PIDs 

such as directions for additional tests and procedures or 2 s f° r a U patients who have data in the patient data repository 

prescriptions for medication to administer to the patient, and 102. All data records related to a patient 211, 212, 213, 214, 

approve recommendations for treatment by other healthcare* 215, 216, 219 include and reference the patient's unique PID 

providers. Las tly, as shown in FIG. 8, a healthcare provider as shown in FIG. 13. 

uses the patient chart window 180"to view ^p^e lTrdataTFirs t, * With reference to FIG. 13, upon creation of a patient 
the h ealthcare provider selects a" view "item _182_b y_either 30 record, the patient locator 200 creates a patient data structure 
pointi ng and clickin g tw ice nn the , it r. m in a list disnlay ed-in 210 having the PID and the patient's name. In a preferred 
the fold er window 184 or by point ing-aLthe-item in the list embodiment, the patient data structure 210 includes pointers 
and pressing the view^bu tton 183. The double click opens a to data structures having data within a patient record cap- 
viewer wJndow^-l^todispla v the view item jj 2. For tured by the point of care system 100 and incorporated from 
exampIeTttieview er window 185 of FIG. 8 display Talfx-ray 35 external sources (e.g., a digital x-ray image file stored in a 
186. As befofeTflie healthcare provider may annotate the raster pixel format). Thus, the patient data structure 210 
x-ray 186-with-commentS"gnTi^bs ervaliolis~b y click ing on maintains a pointer to an interface files structure 211 having 
the annotate-button~187rTtie'liealthcare provider may like- patient data transmitted from external sources. The patient 
wise close thrviewer win^o^w~185-by-clicking.op the close data structure 210 likewise maintains pointers to a clinical 
button 189. 40 data structure 212, a progress note structure 213 and an 
Certain additional structures in the point of care system encounter data structure 214. These data structures include 
10 0 (FIG. 1 ) will now be discussed with reference to FIGS. patient data captured by the clinical data capture 142, 
9 , 10 and 11. Referring now to FIG. 9, an o ptionaLmedica- progress notes 144 and encounter data capture 146, respec- 
tinn riatg c apture 148 supplements the structure of the poi nt tively (FIG. 4). In another preferred embodiment, the patient 
of c are system 100 of FIG. 4. A medication data capture 14 8 45 data structure 210 may include pointers to data structures 
allows a healthcare provider to monitor a patient's medica- having data generated by the reference database 104 and 
tions. The medication data capture 148 communicates with transferred by the legacy data system 106. Thus, the patient 
the patient data capture 140 to account for medications the data structure 210 may maintain pointers to a medication 
patient is currently taking. The medication data capture 148 data structure 215 and a guideline data structure 216. As 
similarly communicates with the progress notes 144, where 50 described above, the medication 215 and guideline 216 data 
a practitioner can monitor changes in a patient's condition structures include patient data captured by the medication 
resulting from medication therapies. Referring now to FIG. data capture 148 and the practice guideline 149, respec- 
10, an optional practice guideline 149 supplements the tively. In this embodiment, a reference data structure 217 
structure of the point of care system of FIG. 4. The practice may maintain pointers to the encounter data structure 214 
guideline 149 provides references for practitioners to consult 55 and to the medication data structure 215 for access to 
regarding courses of action to obtain a diagnosis and alter- reference information contained in a reference database 104. 
native treatments for various conditions. The practice guide- Lastly, the patient data structure 210 may maintain a pointer 
line 149 communicates with the patient data capture 140, the to a legacy files structure 219 having patient data transmitted 
clinical data capture 142 and the encounter data capture 146 from the legacy data system 106, such as an image of a 
to assist the practitioner in selecting the appropriate course 60 patient chart. 

of action. The practice guideline 149 likewise communicates FIG. 14 shows a logical view of a patient record 220 

with the progress notes 144 to provide a healthcare provider corresponding to the structure illustrated in FIG. 13. The 

with a historical context of the patient's condition and patient record 220 includes the PID generated by the patient 

alternative treatments already attempted. locator 200 (FIG. 12) in the patient data repository 102 (FIG. 

FIG. 11 shows a point of care system 100 having a 65 1). In addition, the patient record 220 includes patient data 

medication data capture 148 and a practice guideline 149. As in a variety of data types generated by healthcare providers, 

before, the medication data capture 148 communicates with Thus, the patient record includes text data 223, such as 
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electronic mail and word processing documents from other 
healthcare providers, image data 225, such as scanned 
physical documents, x-rays and CATSCANs, and audio data 
227, such as a physician* s dictation and voice mail. Lastly, 
the patient record 220 has data tables 229, such as a 5 
physician's 1CD9 diagnosis codes and CPT procedure 
codes. In view of the structure of a patient record 220, 
referring back to FIG. 12, the data manager 202 uses the PID 
to store and retrieve patient records. Moreover, the data 
interface 204 permits communication with external sources 10 
to obtain patient data, such as demographic data, laboratory 
test results and x-ray images, and to transfer patient 
information, such as prescriptions for medication, from the 
patient data repository 102 to external healthcare providers. 

With reference to FIG. 12, the patient data repository 102 15 
may optionally include a cache 206 for temporary storage of 
patient data and a data archive 208 for long term storage of 
patient data. In this embodiment, the data manager 202 
coordinates the transfer of patient data to and from a data 
archive 208 into a cache 206. For example, the data manager 2 o 
202 may identify patient records that a healthcare provider 
needs for appointments scheduled at a future time and then 
transfer these patient records from the data archive 208 into 
the cache 206 for quick access prior to the scheduled 
appointment. Similarly, the data manager 202 may purge 2 s 
from the cache 206 records of patients who have not had 
recent appointments and whose records are already 
archived. The data manager 202 likewise tracks the location 
and description of patient data within the data archive 208 by 
associating the file name of the patient data within a patient 30 
record 220 with the patient identifier 221. When possible, 
the data manager 202 will group data associated with a 
patient within the data archive 208 for rapid retrieval in a 
manner similar to files within a directory in an operating 
system. Thus, the data manager 202 assigns a directory to 35 
each patient identifier and then stores patient data within this 
directory. 

FIG. ISa illustrates the process flow for the patient data 
repository 102 (FIG. 1). For example, the point of care 
system 100 (FIG. 1) issues a request for patient data 250. 40 
With reference to FIGS. 15a and 12, the patient locator 200 
receives the request from the point of care system 100 and, 
at 251 attempts to find the PID for the record having the 
requested patient data. As determined at 252, if no PID is 
found, the patient locator 200 reports an error 253. At this 45 
point, the patient data repository 102 (FIG. 1) may recover 
from the error 253 by either restarting the process or by 
ending the process. Otherwise, the patient locator 200 com- 
municates the PID to the data manager 202. The data 
manager 202 locates the patient record using the PID at 254. 50 
As determined at 255, in a system without cache 206 and 
without a data archive 208, the data manager 202 delivers 
the requested data 256 to the point of care system 100. In a 
system having a cache 206 and a data archive 208, the data 
manager 202 determines at 257 if the requested data exists 55 
in the cache 206. If so, the data manager 202 delivers the 
requested data 256 to the requester from the cache 206. 
Otherwise, the data manager 202 first moves the data 258 
from the data archive 208 to the cache 206 and then delivers 
the requested data 254 to the requester from the cache 206. 60 

In addition, FIG. 15b, in conjunction with FIG. 12, 
illustrates the process for transferring data from a cache 206 
to a data archive 208. The data manager 202 monitors the 
contents of the cache 206. To improve the performance of 
the cache 206, the data manager 202 requests transfer 260 of 65 
data to the data archive 208 under certain conditions. For 
example, the data manager 202 may purge the cache 206 
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when data requested for storage in the cache would exceed 
its memory capacity. In this circumstance, the data manager 
202 first transfers to the data archive 208 signed files and 
then data files in chronological order, i.e., oldest files first. 
Similarly, a healthcare provider can specify a predetermined 
time, such as 3 calendar days, or other selected conditions 
for transfer to the data archive 208. As determined at 262, if 
the cache 206 does not have the data to transfer, the process 
ends as the data manager 202 ignores the request. As 
determined at 264, if the data in the cache 206 is not ready 
for transfer, the process ends and the data manager 202 
queues the request for the next transfer of data to the data 
archive 208. Data in the cache 206 is ready for transfer when 
a physician has reviewed and accepted it and when it has not 
been previously committed to the data archive 208. 
Otherwise, the data manager 202 transfers data from the 
cache 206 to the data archive 208 at 266. 

Referring now to FIG. 16, the data interface 204 of the 
patient data repository 102 includes an interface manager 
270, a data handler 272 and a communication interface 274. 
To transfer and receive patient data from* external sources 
(not shown), the interface manager 270 communicates with 
a data handler 272 and a communication interface 274. In 
addition, the communication interface 274 communicates 
with the data handler 272 for conversion of received external 
patient data into formats recognized by the EMR system. 
The interface manager 270 creates and maintains an inter- 
face registry of data formats for external sources. Prior to 
data transfer or receipt by the EMR system, the interface 
manager 270 registers an interface for an external source. 
Upon registration of an interface, the interface manager 270 
can provide the appropriate conversion routines for the data 
handler 272 to use for transfer of data to and receipt of data 
from an external source. These conversions are well under- 
stood by the relevant technologist. 

FIGS. 11a and 17b illustrate the operation of the data 
interface 204 of the patient data repository 102 (FIG. 12). 
Referring now to FIG. 17a, the data manager 202 issues a 
request 280 for patient data from an external source. At 282, 
the interface manager 270 determines if the registry includes 
an interface for the external source, such as a laboratory or 
pharmacy. As determined at 282, if the registry includes an 
interface for the external source, the communication inter- 
face 274 connects to the external source 284 to receive 
patient data. The data handler 272 retrieves the appropriate 
conversion routine for the external source to convert data 
286. In a preferred embodiment, the data handler 272 
converts data from an external source into a database table 
for the appropriate PID. Lasdy, the data manager 202 
incorporates converted data 288 into the patient record. 
Otherwise, the interface manager 270 reports an error 289. 
The data manager 202 may recover from the error 289 in 
several ways. First, the data manager 202 may invoke a 
module to register an interface for the external source so as 
to allow the process to continue. Second, the data manager 
202 may end the process at this point. Lastly, the data 
manager 202 may restart the process in the event the external 
source was specified incorrectly. 

Referring now to FI G. 17b. an external smirc e requests 
data 290'from a patienT^rec g_sjL-As-described->above, the 
interface manager 270 determines at 292 if the reg istry 
includeslin interface for the external source. As determined 
at 292, if-lhe- registiy includes an interface foTlhe ex ternal 
source, the data manager 202 Jo cates_the_requested-data at 
294 antl'tlieHata~Handl er 272 converts req uested data a t 296 
to the foraaalTeqTurecf^ commu- 
nication interface 274 then sends the converted data to the 



05/30/2003, EAST Version: 1.03.0002 



5,924,074 



11 



12 



external source at 298. For ^ypmr^l^Jh? pati p nt Haia-c^pnc;. 
tory 102 may transmit a pn ysiclan's prescription for j nedi- 
cation4e-a-fau suital u r phar macy. It' the regj&U^ineludes no 
interf ace^or^c-ext erna-hsource . the inte ifacs-manager 270 
reports an ^rfoT299 . SimUarlv , jis^disn* ss^-a!^*"* for the 
process flow of FIG. 17a , the interface mana ger 270 may 
recover from the error 299 by restarting the proc ess, end ing 
the process^or-j flveknig a module 10 register ihe exte rnal 

source to allnw'The procegS, to^-nnti'mip 

Referring nowToT^cTl^a block diagram illustrates the 
structure of the optional reference database 104 (FIG. 1). 
The reference database 104 includes a diagnosis module 
300, a medication manager 302 and a procedure module 
304, A healthcare provider can use the reference database 
104 for assistance in diagnosing a patient's disease, pre- 
scribing medications and ordering supplemental procedures 
to treat the disease. The diagnosis module 300 communi- 
cates with a medication manager 302 to obtain information 
on medications indicated by a diagnosis. The medication 
manager 302 provides information on medications, such as 
proper dosages, allergies, contraindications, adverse inter- 
actions with other medications, and side effects. The diag- 
nosis module 300 likewise communicates with a procedure 
module 304 to obtain information on the proper adminis- 
tration of procedures indicated by a diagnosis. The proce- 
dure module 304 provides information on procedures for 
treatment as indicated by the diagnosis. In many instances, 
the medication manager 302 communicates with the proce- 
dure module 304 regarding the administration of various 
medications. 

In a preferred embodiment, the point of care system 100 
provides access to the reference database 104 through a 
graphical user interface having a patient chart window 310 
shown in FIG. 19. A healthcare provider accesses the 
diagnosis module 300 and the procedure module 304 by 
pointing and clicking on a reference access button 312. 

As shown in FIG. 20, the reference access button 312 
produces a reference window 330 including the graphical 
interfaces for the diagnosis module 300 and the procedure 
module 304. For example, to enter a diagnosis, a physician 
clicks on the scroll down button 331 adjacent to the system 
box 332 to produce a list of body systems. The physician 
selects the appropriate system and the diagnosis module 300 
enters the selected system in the system box 332 and 
provides a list having specific diagnosis codes for the 
selected body system in the diagnosis box 334. The physi- 
cian then selects the appropriate diagnosis code and clicks 
on the add button 336 adjacent to the diagnosis selection box 
337. The diagnosis module 300 enters the selected diagnosis 
code to the diagnosis selection box 337. The physician may 
repeat the above steps to add multiple diagnosis codes to the 
diagnosis selection box 337. In a similar manner, a physician 
uses the scroll down button 331 adjacent to the topic box 333 
to select the appropriate procedure topic. The procedure 
module 304 enters the selected procedure topic in the topic 55 
box 333 and provides a list of procedure codes in the 
procedure box 335. The physician now selects the appro- 
priate procedure code and adds it to the procedure selection 
box 338 by clicking on the add button 336 adjacent to the 
procedure selection box 338. The physician may likewise 
repeat the above steps to add multiple procedure codes to the 
procedure selection box 338. The physician completes entry 
of diagnoses and procedures by clicking on the done button 
339 to return to the patient chart window 310 of FIG. 19. 

The healthcare provider similarly accesses the medication 
manager 302 (FIG. 18) by clicking on a medication button 
192 (FIG. 19). Referring now to FIG. 21, the medication 



button 314 activates a medication manager window 350. The 
physician can review the patient's history by viewing the 
medication history box 351 and the diagnosis history box 
352 before prescribing any new medications. The physician 
5 can also review any patient allergies in the allergy box 353. 
The physician can select a medication by entering the name 
of the medication in the name box 354. Note that as the 
physician enters the root letters of a medication name, a list 
of medications with the root letters appears in the medica- 
10 tion list box 355. As before, the physician selects a medi- 
cation from the list by clicking on it and the medication 
manager 302 places the selected medication in a selection 
box 356. If there are no contraindications or allergies for the 
patient, the physician prescribes the medications listed in the 
15 selection box 356 by clicking on the prescribe button 357. 
Otherwise, if a contraindication exists, a warning appears 
in a warning bar 358 to alert the physician. In view of the 
warning, the physician can investigate the effects of the 
medication by clicking on the results button 359. Referring 
20 now to FIG. 22, the results button produces a medication 
interaction window 361. A medication selection box 362 
displays the medications selected and under consideration 
by the physician. An allergy list box 363 displays the 
patient's allergens. Folder tabs 364 include labels describing 
25 the medication combinations and interactions. The physician 
clicks on one of these folder tabs 364 to display the contents 
of the folder in the viewing box 365. The physician can then 
evaluate the information on the interaction including poten- 
tial adverse patient reactions. The physician clicks on the 
30 done button 366 to return to the medication manager win- 
dow 350 of FIG. 21. The physician can make any needed 
revisions to the medications selected in the manner 
described above. Afterwards, the physician exits the medi- 
cation manager 302 by clicking on the exit button 360. 

Referring now to FIG. 23, a block diagram illustrates the 
structure of the optional legacy data system 106 as shown in 
FIG. 1. The legacy data system 106 includes a data source 
370 and a converter 372. The data source 370 comprises 
physical data 374, such as paper based records and 
photographs, and electronic mainframe data 376. The con- 
verter 372 receives information from the data source 370 
and transforms the information into an electronic format 
compatible with the EMR system. For example, to input 
physical data 374, such as paper or image based data, into a 
patient record, the converter 372 comprises a scanner to 
digitize the physical data into a binary file format for 
incorporation into the patient's record. To input electronic 
mainframe data 376, the converter 372 employs the same 
mechanism used for transfer or receipt of patient data from 
external sources. As described before, the converter 372 
determines if an interface exists for the mainframe data, 
selects the appropriate data handler and converts the data 
into the proper format for incorporation into a patient record. 

II. EMR System Configurations 

FIG. 24 illustrates one possible configuration for the EMR 
system of the present invention. The system comprises a 
wide area network (WAN) 402, the World Wide Web (Web) 
404 portion of the Internet, and remote web servers 406, 
408, 410 communicating with web browsers 412. The WAN 
402 comprises a plurality of local area network (LAN) 
servers supporting local and remotely located healthcare 
providers. For example, the WAN 402 includes LANs sup- 
porting Scripps Health 414 and Sharp Memorial 430 in San 
Diego and Cedars Sinai 432 and Loma Linda 434 in Los 
Angeles, Calif. In one presently preferred embodiment, the 
server comprises a multi-processor personal computer hav- 
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ing Intel Pentium processors, such as a Compaq Proliant 
4500R 5/100 Model 2, communicating with a fault tolerant, 
error correcting storage device, such as a Hewlett Packard 
20XT Optical Jukebox having 20 gigabytes of storage 
capacity. The LAN 400 includes a backup server 426 and 
several peripherals, such as a scanner 424 to input docu- 
ments and a laser printer 422 to print out documents. In a 
preferred embodiment, the LAN backbone comprises an 
Ethernet twisted pair cable configured in a general star 
topology. Similarly, the scanner 424 comprises a Fujitsu 
M3093EX scanner using Kofax KIPP ImageControls soft- 
ware and the laser printer 422 comprises a Hewlett Packard 
LaserJet 4Plus. Healthcare providers may access the LAN 
400 using a desktop computer 416, a laptop computer 418 or 
wireless pen computer 420. In a preferred embodiment, the 
desktop computer 416 comprises a Compaq Deskpro 5/75 
Model 630, the laptop computer 418 comprises a IBM 
ThinkPad 760CD and the pen computer 420 comprises a 
Fujitsu Stylist 1000 configured with a Solectek AirLAN 
PCMCIA network adapter for wireless LAN access. The 
EMR system also provides for communication through the 
World Wide Web. For example, remote healthcare providers 
may access the WAN 402 on the Web using the domain 
name "www.westcst.com" 436. Thus, a healthcare provider 
located in Boston, Mass. may access a patient record resi- 
dent on the Scripps Health server 414, located in San Diego, 
Calif., using a web browser 412, such as Microsoft Explorer 
or Netscape Navigator, communicating with a Web server in 
Boston, Mass. having the domain name "www.boston.com** 
406. 

In a preferred embodiment, servers 414, 426, desktop 416, 
or laptop 418 computers and peripherals, such as printers 
422 or scanners 424, communicate with each other and with 
the Web using a network operating system, such as 
Microsoft Windows NT, Windows 95 or Windows for Work- 
groups. Similarly, pen computers 420 use the Microsoft 
Windows for Pen Computing operating system. In another 
preferred embodiment, the servers, computers and periph- 
erals communicate using an operating system supporting 
Web browsers on computer networks, such as Unix, Novell 
Netware or Apple System 7.0. In yet another preferred 
embodiment, the EMR system includes servers, computers 
and peripherals networked using mixed network operating 
systems, such as Unix, Netware and Windows. For example, 
the LAN 400 may operate on a Windows NT network 
operating system, whereas the LAN 430 may operate on an 
Apple System 7.0 network, and the Web server "www.bos- 
ton.com*' .406 may operate on a Unix operating system. 
Thus, the EMR system supports communication among a 
variety of hardware components, such as printers 422, 
scanners 424 and pen computers 420, using a variety of 
network operating systems, such as Windows, Netware or 
Unix. In a preferred embodiment, healthcare providers, such 
as clinics and laboratories, may also communicate with the 
EMR system using modem links and standard v.34 modem 
devices, such as a US Robotics Sportster 28,800 modem. 

The EMR system includes several databases of electronic 
information, such as the medication manager 302 and the 
data manager 202. In a preferred embodiment, the EMR 
system implements a relational database language that con- 
forms to American National Standards Institute (ANSI) 
standard SQL-92, a 580 page specification for the SQL 
relational database language. A database language standard 
specifies the semantics of various components of database 
management systems (DBMS). In particular, it defines the 
structures and operations of a data model implemented by 
the DBMS, as well as other components that support data 
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definition, data access, security, programming language 
interface and data administration. The SQL-92 standard 
specifies data definition, data manipulation, and other asso- 
ciated facilities of a DBMS that supports the relational data 

5 model. SQL is old in the art and additional information on 
SQL-92 is available in ANSI specification X3.135-1992, 
hereby incorporated by reference. 

Similarly, in another preferred embodiment, relational 
databases in the EMR system support the Open Database 

10 Connectivity (ODBC) model. ODBC is an application pro- 
gram interface (API) that allows client applications running 
under Microsoft Windows to access data from a variety of 
data sources, including relational and non-relational DBMS. 
These data sources may reside on a client machine or they 

1 5 may be located on a remote server communicating through 
a network common to the client machine. Under ODBC, 
data sources may vary in complexity from shrink-wrap 
databases, such as Microsoft Access, running under Win- 
dows on a client machine to more sophisticated, proprietary 

20 relational DBMS running on a Unix server or mainframe 
computer. For a client application to access data from a data 
source, a dynamic link library (DLL) driver must exist for 
each data source to be accessed. For additional information 
on ODBC is available from Inside ODBC, by Karl Geiger, 

25 hereby incorporated by reference. 

II. SUMMARY 

The electronic medical record system of the present 
invention advantageously overcomes several limitations of 

30 existing technologies and alternatives. Because it is more 
efficient and cost effective to move data, instead of physical 
records and healthcare providers, the present invention 
eliminates the need to create and maintain any physical data 
records. In contrast to other systems, the present invention 

35 creates and maintains all patient data electronically. Thus, 
there is no need to find, pull, move, update, file and replace 
physical charts. As a result, healthcare providers no longer 
require substantial shelving and storage space for physical 
files. The present invention likewise eliminates the 

40 mishandling, loss and destruction of patient data typically 
associated with maintenance of physical data records. 

Using the present invention, healthcare providers enter 
patient data immediately at the point of care. Thus, the EMR 
system captures each piece , of data at its source at the time 

45 of entry, including time and healthcare provider identifica- 
tion. The EMR system thus provides a complete audit trail 
for all patient data. The audit trail, in turn, permits inexpen- 
sive analysis of outcomes, utilization and compliance. For 
example, outcomes typically refer to the effectiveness of a 

so treatment plan. Thus, the EMR system enables a healthcare 
provider to analyze patient recovery times and incurred costs 
to measure the efficacy of the treatment plan. Similarly, 
utilization typically refers to how well available resources 
are utilizing time. Thus, the EMR system provides the 

55 capability to analyze utilization of physicians, nurses, staff 
and equipment as well as time utilization for patients, such, 
as wait times for referrals, lab results and physician exami- 
nations. Lastly, compliance typically refers to conformance 
with government and accreditation standards and regula- 

60 tions. The EMR system provides tools to enable healthcare 
providers to measure conformance to standards and regula- 
tions. To facilitate entry of patient data at the point of care, 
the invention provides touch screens for entry of lab orders, 
medications, diagnoses and procedures. The invention like- 

65 wise provides instant access to a patient's electronic medical 
record by authorized healthcare providers from any geo- 
graphical location. Thus, the EMR system enables autho- 



05/30/2003, EAST version: 1.03.0002 



5,924,074 



15 



16 



10 



rized healthcare providers to access and update patient files, 
using wireless pen-based personal computers. In addition, 
authorized healthcare providers can access a record while 
other healthcare providers use the same record. By provid- 
ing simultaneous access to patient data, the present inven- 
tion enables real-time collaboration among multiple health- 
care providers. 

The availability of electronic data permits instant, sophis- 
ticated analysis of a patient's clinical data. Thus, the EMR 
system can create graphs of a patient's vital signs and lab 
results or the system can provide an analyze patient infor- 
mation to identify medication interactions and allergies. 
Using the present invention, a healthcare provider can 
likewise select, sort, and analyze patient data to identify is 
relationships among the data considered. In addition, the 
EMR system provides flexibility in the creation and main- 
tenance of patient data repositories. Thus, the present inven- 
tion can support a large healthcare enterprise distributed 
across a large geography as well as a single physician office. 20 
Moreover, the present invention ensures patient confidenti- 
ality through the use of a tiered password system. The EMR 
system provides several levels of security for access to 
patient data. For example, a system administrator may have 
global password access to any patient data for system 25 
maintenance and debug purposes, whereas physicians may 
have access only to patient records within their specialty and 
nurses and staff may have access to only those patient 
records within their immediate care. In addition, a patient 
may request restricted access to their data by only certain 30 
personnel. Thus, in contrast to physical records, the EMR 
system provides superior protection of patient data. 

In addition, the present invention is useful in legal, 
manufacturing and general administration environments. 
For example, the present invention is capable of organizing, 
maintaining and protecting legal files in an attorney's office. 
Thus, the EMR system can store and retrieve scanned 
images of paper documents, such as deeds and assignments, 
as well as other native file formats, such as word processing 
files. The EMR system organizes and retrieves this data in a 
manner akin to that of a patient's medical record. Upon entry 
of a client data into the EMR system, attorneys can annotate 
documents, transfer information to and from other systems, 
or create new data for automatic filing in the client or case 
file. Similarly, the EMR system is useful for management of 
procurement or regulatory data in a manufacturing context. 
Thus, the EMR system can organize and maintain material 
safety data sheets (MSDS) as well as other data pertinent to 
materials procurement, such as conformance to specification 
measurements and inspection data for received lots, in a 
manufacturing environment. Lastly, the EMR system is 
useful for general administrative files in any organization. 
For example, the present invention is applicable to employee 
files in human resources, customer files in sales and 
approved suppliers in procurement. The EMR system can 
organize and retrieve data within these files in the manner as 
patient data in a patient data record. As discussed above, 
upon entry of a data into the EMR system, users can annotate 
documents, transfer information to and from other systems, 
or create new data for automatic filing in the respective file. 

Those skilled in the art may practice the principles of the 
present invention in other specific forms without departing 
from its spirit or essential characteristics. Accordingly, the 
disclosed embodiments of the invention are merely illustra- 
tive and do not serve to limit the scope of the invention set 
forth in the following claims. 
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What is claimed is: 

1. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care wherein the point of care system comprises: 

patient data capture to enter information provided by a 
patient, 

a clinical data capture, in data communication with the 
patient data capture to enter clinical data for the patient, 

an encounter data capture, in data communication with 
the patient data capture, to enter diagnoses and proce- 
dures administered to the patient, and 

progress notes, in data communication with the patient 
data capture, the clinical data capture and the encounter 
data capture, to enter information related to changes in 
the patient's condition, and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system. 

2. The medical records system of claim 1, further com- 
prising a medication data capture, in data communication 
with the patient data capture and the progress notes, to enter 
medication information for the patient. 

3. The medical records system of claim 1, further com- 
prising a practice guideline for reference to accepted medi- 
cal practices, wherein the practice guideline communicates 
with the patient data capture, the clinical data capture, the 
progress notes and the encounter data capture. 

4. The medical records system of claim 3, further com- 
prising a medication data capture, in data communication 
with the patient data capture, the progress notes and the 
practice guideline, to enter medication information for the 
patient. 

5. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system, wherein the patient data repository comprises a 
server computer having access to patient data stored in 
a relational database that accepts SQL data queries. 

6. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system, wherein the patient data repository comprises a 
server computer having access to patient data stored in 
a relational database that is ODBC compatible. 

7. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; and 

a patient data repository, in communication with the point 
of care system and with external' systems, to store and 
organize the patient data for access by the point of care 
system, wherein the patient data repository comprises: 
a patient locator having a patient identifier, 
a data manager, in communication with the patient 
locator, to organize patient data for storage and 
retrieval using the patient identifier, and 
a data interface, in communication with the data 
manager, to transmit patient data to external systems 
and to receive patient data from the external systems. 
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8. The medical records system of claim 7, wherein the 
patient data repository further comprises: 

a cache, in communication with the data manager, to 
temporarily store the patient data for retrieval; and 

a data archive, in communication with the cache, to 
permanently store the patient data. 

9. The medical records system of claim 8, wherein the 
cache is located on a server computer. 

10. The medical records system of claim 8, wherein the 
cache is distributed across a computer network. 

11. The medical records system of claim 8, wherein the 
data archive comprises a jukebox having at least one storage 
device. 

12. The medical records system of claim 11, wherein the 
at least one storage device is a recordable optical disk. 

13. The medical records system of claim 11, wherein the 
at least one storage device is a magnetic disk drive. 

14. The medical records system of claim 7, wherein the 
data interface comprises: 

a communication interface to send and receive patient 
data from external systems; 

an interface manager, in communication with the com- 
munication interface, to set the communication inter- 
face for either transmission or receipt of the patient data 
from the external systems; and 

a data handler, in communication with the interface 
manager and with the communication interface, to 
convert selected patient data into a selected data format. 

15. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system; and 

a reference database in communication with the point of 
care system. 

16. The medical records system of claim 15, wherein the 
reference database comprises: 

a diagnosis module having diagnosis codes indicative of 
a condition of a patient; 

a procedure module, in communication with the diagnosis 
module, having procedure codes indicative of a treat- 
ment to administer to the patient; and 

a medication manager, in communication with the diag- 
nosis module and with the procedure module, having 
information on medication to administer to the patient. 

17. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system; and 

a legacy data system in communication with the patient 
data repository. 

18. The medical records system of claim 17, wherein the 
legacy data system comprises: 

a data source having patient data; and 

a converter, in communication with the data source, to 

convert the patient data into a selected format for 

transfer to the patient data repository. 

19. The medical records system of claim 18, wherein the 
data source comprises physical data. 
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20. The medical records system of claim 18, wherein the 
data source 20 comprises a mainframe computer having 
electronically stored patient data. 

21. The medical records system of claim 18, wherein the 
converter comprises a scanner. 

22. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care wherein the point of care system provides for 
annotation of the patient data; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system. 

23. The medical records system of claim 22, wherein the 
annotation acknowledges review of the patient data. 

24. The medical records system of claim 22, wherein the 
annotation includes instructions for patient care. 

25. The medical records system of claim 22, wherein the 
annotation indicates approval. 

26. A medical records system, comprising: 

a point of care system to capture data at a point of care; 
and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the data in a patient record for access by the 
point of care system, wherein the data comprises inter- 
face files and wherein the patient record includes, 
a patient identifier, and 

at least one data structure including the patient identi- 
fier and the data. 

27. A medical records system, comprising: 

a point of care system to capture data at a point of care; 
and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the data in a patient record for access by the 
point of care system, wherein the data comprises legacy 
files and wherein the patient record includes, 
a patient identifier, and 

at least one data structure including the patient identi- 
fier and the data. 

28. A method of using an electronic medical records 
system, comprising the steps of: 

capturing patient data electronically at the point of care; 
organizing the patient data so as to form a patient record; 
filing the patient record; and 

retrieving the patient record to access the patient data for 
use in the care of a patient. 

29. The method of claim 28, wherein the step of retrieving 
the patient record includes annotating the patient data. 

30. The method of claim 28, further comprising the step 
of evaluating the patient data so as to make a diagnosis. 

31. The method of claim 30, wherein the step of evalu- 
ating the patient data comprises consulting a diagnosis 
module to review diagnosis information. 

32. The method of claim 30, further comprising the step 
of prescribing a medication. 

33. The method of claim 32, wherein the step of prescrib- 
ing a medication comprises consulting a medication man- 
ager to review medication information. 

34. The method of claim 30, further comprising the step 
of administering a treatment. 

35. The method of claim 34, wherein the step of admin- 
istering a treatment comprises consulting a procedure mod- 
ule to review procedures to administer the treatment. 
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36. A method of retrieving patient data in an electronic 
medical records system having a patient data repository, 
comprising the steps of: 

obtaining a patient identifier; 

locating a patient record corresponding to the patient 

identifier in the patient data repository; 
determining the location of the patient data within the 

patient record. 

37. The method of claim 36, further comprising the step 
of delivering the patient data. 

38. The method of claim 36, wherein the patient data 
repository includes a cache and a data archive. 

39. The method of claim 38, further comprising the step 
of delivering the patient data when the patient data is located 
in the cache. 

40. The method of claim 38, further comprising the steps 

of: 

moving the patient data from the data archive when the 

patient data is not located in the cache; and 
delivering the patient data. 

41. A method of managing a patient data repository 
having a cache and a data archive, comprising the steps of: 

monitoring a status of data within the cache; and 
moving the data to the data archive when the status 
exceeds a threshold. 
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42. The method of claim 41, wherein the threshold 
comprises a selected time and the status comprises the 
duration of time the data has been in the cache. 

43. The method of claim 41, wherein the threshold 
comprises a selected portion of the storage capacity of the 
cache and the status comprises the filled portion of the 
cache. 

44. A method of communicating with an external source 
having an interface to an electronic medical records system, 
comprising the steps of: 

finding an interface for the external source; 
connecting. to the external source using the interface; and 
converting patient data for transfer between the external 
source and the electronic medical records system. 

45. The method of claim 44, wherein the step of convert- 
ing patient data for transfer comprises converting patient 
data for transfer from the electronic medical records system 
to the external source. 

46. The method of claim 44, wherein the step of convert- 
ing patient data for transfer comprises converting patient 
data for transfer from the external source to the electronic 
medical records system. 

***** 
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